Software customization system and method

ABSTRACT

A system and method for the mass customization of software includes a software production line infrastructure, development environment, and actuator. The infrastructure organizes the software production line using a feature declarations component, a product definitions component, an automatons component, and a partition composition component. The development environment browses, displays, organizes, edits, and maintains the infrastructure. The actuator actuates the software production line to produce custom software products.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication No. 60/278,786 filed Mar. 26, 2001.

BACKGROUND OF THE INVENTION

1. Field

The present invention pertains to the creation of software; moreparticularly, the present invention pertains to the creation ofindividual software products that are part of a software product familyusing a software production line.

2. Background

A software product family is a collection of almost-alike individualsoftware products, each of which individual software product has someunique features and some common features found in all of the individualsoftware products within the software product family. Software productfamilies are typically created to satisfy a common need shared by manycustomers or market segments while at the same time accommodating theunique requirements of individual customers or market segments for aspecially tailored individual software product.

Most software development organizations have a need to create andmaintain multiple nearly-identical software systems. For example, amobile phone manufacturer may have to produce hundreds of individualvariations of the software which operates its handsets, one softwarevariation for each handset model and wireless service provider used bythe handset. Although most of the software for the hundreds ofcombinations of handsets and wireless service providers is virtuallyidentical, each individual software product has small, but extremelyimportant, variations which enable the operation of different handsetfeatures with the different features offered by the available array ofwireless service providers.

Conventional approaches to developing individual software products havefocused on creating and maintaining a one-of-a-kind software productrather than creating a family of nearly identical software products.Accordingly, the use of conventional approaches to create softwareproduct families including nearly-identical, but individualized,software products has been costly, slow, and often prone to errors.

One approach to reducing cost, speeding up the process of softwarecreation, and reducing errors in the creation of software productfamilies is the process of software mass customization. The process ofsoftware mass customization focuses on the means for efficientlyproducing and maintaining multiple similar software products, exploitingwhat the multiple similar software products have in common, and managingthe differences among the individual software products. A betterunderstanding of the process of software mass customization can be hadby making an analogy to the automotive industry. In the automotiveindustry, the manufacturing of automobiles focuses on the use of asingle production line to produce multiple similar variations of aparticular car model. The powerful, though subtle, essence of thisanalogy to the production of multiple similar cars is the focus on asingular means of production for software rather than focusing on thecreation of many similar individual software products. Once a process ofsoftware mass customization has been established, the actual productionof the individual software products is more a matter of automatedinstantiation to create multiple individual software productsefficiently rather than making the many small programming languagechanges associated with the manual creation of each individual softwareproduct in a software product family.

Actual success stories of the use of software mass customizationtechniques exist in such diverse areas as the software used with mobilephones, e-commerce, computer printers, diesel engines, telecom networks,enterprise software, cars, ships, and airplanes. The software systemassociated with each one of these examples relies on creating andmaintaining a collection of individual but similar software products. Byusing the process of software mass customization to exploit what theirindividual software products have in common and to effectively managethe variation between their various software programs, companies haveseen the potential for major reductions in time-to-market, engineeringoverhead and error rates in the creation of new almost-alike individualsoftware products.

Many of the companies who have had success with the use of software masscustomization techniques have also reported that the process of softwaremass customization continues to present formidable technical challenges.Accordingly, the complexity associated with the process of software masscustomization results in large adoption times and efforts forestablishing new software production lines.

Newcomers to the process of software mass customization often believethat the process involves simply building a single software system andthen building a collection of small variations within the singlesoftware system using tools and techniques developed for the creation ofspecial use software products. To date, however, no formal tools ortechniques for building and managing a large and diverse collection ofsmall variations in the individual software products in a softwareproduct family have been developed.

One attempt to solving the problem of building and managing a collectionof small variations for a software product line includes the reliance oninformally contrived solutions such as preprocessors, namingconventions, directory structure conventions, configuration files, builddirectives, assembly scripts, install scripts, and parallelconfiguration management branches. It has been found, however, thatthese informally contrived solutions are not scalable; specifically,they are not manageable beyond a small number of software productvariations. Moreover, these informal solutions are code-level mechanismsthat are poorly suited for the expression of product-level constraints.

The problem remains, therefore, to create a robust system and method forthe creation of individual software products in a software productfamily. The desired system and method must provide for the building andmanaging of a large collection of small variations among a group ofindividual software products within the software product family. Thedesired system and method should also minimize technical complexity,maximize reuse of existing software, present a low cost to the softwaredeveloper, be easy to adopt, and enable the rapid production ofindividual software products that are part of a software product family.

SUMMARY

The disclosed system and method for software mass customization providesa software developer the tools and techniques for building and managinga collection of small variations among individual software productswhich are part of a software product family. Technical complexity,adoption effort, and production times are minimized by the presentinvention while at the same time maximizing reuse of existing software.

The disclosed system and method for software mass customization enablesthe creation of a software production line. Specifically, the presentinvention includes an infrastructure which allows all files anddirectories for a software product family to be stored unmodified in acommon structure for all individual software products within thesoftware product family. Common data files and data file directories forthe individual software products are stored “as is” using conventionalfiles and directories. For the data files and data file directorieswhich vary among the individual software products, a new construct isused. This new construct is called an automaton and has two forms, afile automaton and a directory automaton. The construct of an automatonis introduced to augment the conventional notion of data files and datafile directories. A file automaton is a virtual data file that actuallyappears as a different data file in each of the different softwareproducts. Similarly, a directory automaton is a virtual data filedirectory which can appear as a different data file directory in each ofthe individual software products within the software product family.

Each file automaton or directory automaton contains an executabledescription for creating a real data file or real data file directory inplace of the virtual data file or virtual data file directory itrepresents within the individual software product. This executabledescription of the file automaton or directory automaton is called theautomaton logic. The process of executing the automaton logic to createa real data file or a real data file directory in place of the virtualdata file or virtual data file directory is called automaton actuation.

The automaton logic or the executable description for creating a realdata file or a real data file directory is parameterized.Parameterization of the automaton logic allows different real data filesor different real data file directories to be produced upon automatonactuation with different parameter values. All of the various fileautomatons or directory automatons are actuated with a given set ofparameter values to produce each individual software product in thesoftware product family. Because each file automaton or each directoryautomaton encapsulates everything needed to actuate itself, the fileautomatons and the directory automatons are called self-configuringautomatons.

With each self-configuring automaton, the automaton logic for selectingor constructing the different variants is stored externally from thesoftware artifacts. That is, the self-configuring software masscustomization infrastructure does not require the contents of the sourcefiles and directories to be modified or for the automaton logic to beinserted into the source files and directories.

Accordingly, the disclosed system and method enables software developerswho create individual software products that are part of a softwareproduct family to create and maintain a product line of individualizedsoftware products with the efficiency of mass production.

DESCRIPTION OF THE DRAWING FIGURES

A better understanding of the present invention may be had by referenceto the drawing figures wherein:

FIG. 1 is a schematic diagram showing the relationship of the disclosedsoftware mass customization system and method to conventional softwaretechnology development layers;

FIG. 2 is an edit screen from the software development environmentshowing a collection of product features;

FIG. 3 is an edit screen similar to FIG. 2 from the software developmentenvironment showing a product definition;

FIG. 4 is an edit screen from the development environment which viewsthe automaton logic;

FIG. 5 is a schematic diagram of the high level tasks for the proactiveapproach;

FIG. 6 is a schematic diagram of the high level tasks for the reactiveapproach;

FIG. 7 is a schematic diagram of the high level tasks for the extractiveapproach;

FIG. 8 is a browser screen from the software development environment ;

FIG. 9 is a schematic showing the creation of a customized softwareproduct; and

FIG. 10 is a schematic diagram of the high level tasks associated withthe creation of a Globalization/Localization Software Production Line.

DESCRIPTION OF THE EMBODIMENTS

The disclosed system and method for software mass customization bringstogether and expands on the two basic tenets of software masscustomization which are: i) individualized software products, and ii)the efficiency of mass production. Unlike prior art software masscustomization systems, the disclosed system and method for software masscustomization focuses on the improvement provided by the mass productionaspect of creating individualized software products rather than on themanual creation of each individual software product in a softwareproduct family and the improvement provided by augmenting existingtechnology and software with software mass customization support ratherthan requiring existing technology and software to be replaced.

In a macro sense, the disclosed system and method for software masscustomization is based on an infrastructure which includes the followingcomponents:

-   -   i) Parameterized file and directory automatons which represent        virtual data files and virtual data file directories that vary        from individual software product to individual software product        within a software product family. Each parameterized file or        directory automaton represents a virtual data file or virtual        data file directory and is inserted “in place” among the        conventional data files and data file directories within the        software artifacts common to the other individual software        products in a software product family.    -   ii) A mechanism for actuating each file or directory automaton        by which each file or directory automaton receives parameter        values and is thereby actuated to instantiate the appropriate        real data file or real data file directory “in place” among the        conventional data files and data file directories within the        software artifacts common to the other individual software        products in a software product family for the virtual data file        or virtual data file directory represented by the automaton.        Automaton actuation can be implemented in a variety of different        ways: One way of automaton activation is to select from among a        collection of existing files to present the real file. A second        way of automaton actuation is to generate programming code from        scratch. A third way is to transform existing source code into        different forms. A fourth way is to instantiate patterns or        frameworks. Those of ordinary skill in the art will understand        that any combination of the enumerated ways of automaton        actuation may also be used.    -   iii) A mechanism by which the parameters that can affect the        behavior of each file or directory automaton can be declared.    -   iv) A mechanism for defining the parameter values that are used        to actuate all of the file and directory automatons to produce        an individual software product within a software product family.        Each individual software product will have its own set of        parameter values that will actuate each file or directory        automaton to produce the desired real data files and real data        file directories in place of the virtual data files and virtual        data file directories.

A still better understanding of the disclosed system and method may behad from the following more detailed description. The infrastructure ofthe present invention and the development environment for creating asoftware mass customization production line is much like an automobileproduction line that is used to manufacture or produce customizedvariations of a single car model. Specifically, the disclosed system andmethod creates a single software production line out of which manycustomized variations of individual software products can be produced.

In an automobile production line, a chassis and drive train provide thebasic structure to which is added a designated body style and optionalfeatures at predetermined locations. In the disclosed system and method,virtual data files and virtual data file directories are created. Thesevirtual data files and virtual data file directories resemble the realdata files and real data file directories which must be present in afinished software product for it to be operational, and they areconvertible into the real data files and real data file directorieswhich are present in a finished software product. Further, these virtualdata files and virtual data file directories are incorporated in withthe software artifacts on which a family of software products is basedwhere the real data files and real data file directories are to belocated in the finished software product. Inputs, according to apredetermined set of parameters, are provided to the virtual data filesand virtual data file directories. These inputs create predeterminedresponses by the virtual data files and virtual data file directories.Such predetermined responses transform non-functional software includingsoftware artifacts, virtual data files, and virtual data filedirectories into a functional software product including softwareartifacts, real data files, and real data file directories.

For example, consider a software developer that has manually createdthree different variations of a software product for three differentcustomers or three different market segments. Because each individualsoftware product customization was created under different productiondeadlines, three independent copies of the software product were createdin parallel. However, the parallel maintenance of these three individualsoftware products rapidly grows in complexity because bug fixes andupgrades have to be performed three times for three copies and becauseof the continuing demand for more and more customized variations of thebasic software product.

According to the disclosed system and method, the three independentvariations of the software product for three different customers ormarket segments would be consolidated into a single software masscustomization production line. That portion of the software artifactsthat is common among all three independent variations of the softwareproduct is factored out into a single copy. For that portion of thesoftware artifacts that varies among the three independent softwaresystems, the system and method of the present invention encapsulatesinto automatons the differences at the point of variation in thesoftware artifacts, along with the logic descriptions, for choosingamong the differences in the software artifacts at the time ofproduction. In some prior art software mass customization systems, thevariations are made by going back into a completed software product withthe necessary changes to the programming code to customize an individualsoftware product for a particular application.

By use of the disclosed system and method, each individual softwareproduct can now be produced using a single software production line.Specifically, the three individual software products described above canbe easily assembled from the software production line. Maintaining andenhancing these and other software products is accomplished by modifyingthe software production line to accommodate new products, requirements,or defects in existing software products. A key difference of thisinvention from other prior art software mass customization techniques isthe shift of focus from developing and maintaining three separate,individual software products to developing and maintaining a singleproduction line for automatically instantiating individual softwareproducts.

Another key difference of this invention from other prior art softwaremass customization is that the disclosed system and method works at thegranularity of the data files within a software program. By notintruding into existing data files within a software program, thedisclosed system and method remains neutral to programming language,compilers, operating systems, and editors. Additionally, the disclosedsystem and method will work equally well with data files that containsource code, documentation, test cases, requirements, and even binarymultimedia data files.

FIG. 1 illustrates where the disclosed software mass customization layer10 fits in relative to conventional software technology developmentlayers. At the bottom layer is the operating system's data file system.Configuration management will extend the operating system's data filesystem by providing management of data file and system versions thatchange over time. The disclosed system and method extends the operatingsystem's data file system by providing mass customization of systemversions that may vary at fixed points in time.

Accordingly, the present invention is a method for managing thevariation that exists in a family of individual software products.Execution of the method begins by first creating a set of abstractdimensions in the variations in the software artifacts among eachindividual software product. Next, a characterization is made of whereeach individual software product in the family of related softwareproducts is with respect to the created set of abstract dimensions inthe variations in the software artifacts. Third, the locales ofvariation of the software artifacts of each individual software productare identified and an automaton is created at each locale of variation.Within the automaton for each locale of variation, the variations ofsoftware artifacts are then characterized in terms of the abstractdimensions of variation so that they may be instantiated at theidentified locales of variation of the software artifacts in eachindividual software product. Instantiation of a software product occursby selecting an individual software product in the abstract dimensionsof variation and actuating each automaton with this software productdescription.

Using the method disclosed in the foregoing paragraph, an individualsoftware product may be customized for an anticipated variation in thefunctionality of that individual software product. Alternatively, theindividual software product may be customized to respond to anunanticipated variation in the functionalities of an existing softwareproduct. Or, the existing software product may be customized byextracting, or reverse engineering, information from an existingsoftware product.

The software product created by using the disclosed method will includeall of the common data files and common data file directories from thesoftware production line, plus real instantiations for each of thevirtual data files and virtual data file directories which are locatedat the identified locales of variation within a software productionline. The creation of a real data file or real data file directory istriggered using a given set of parameter values.

A still better understanding of the present invention may be had byunderstanding that the disclosed system and method includes a masscustomization infrastructure, a mass customization developmentenvironment, and a mass customization actuator.

The infrastructure portion of the disclosed system and method structuresthe set of individual software products to be produced into a masscustomization production line. The mass customization developmentenvironment of the disclosed system and method includes editors andbrowsers which display, create, modify, and maintain the productdefinitions, the automatons, the partition composition, and a collectionof mass customization infrastructure and software artifacts for thesoftware production line. The mass customization actuator then activatesthe software production line to produce individual software products.

The software mass customization infrastructure of the disclosed systemand method has four major components. These components are featuredeclarations, product definitions, and automaton and partitioncomposition.

The feature declarations component models the scope or dimensions ofvariation that can be used in the software production line. FIG. 2displays a feature declaration editor 20 from the software developmentenvironment which includes a collection of feature declarations in themass customization infrastructure. As shown in FIG. 2, there aredeclarations of four features 21, 22, 23 and 24 that can vary in thesoftware production line, which, as shown in FIG. 2, is an automotivee-commerce website.

Specifically, the auto locator Feature 21 in FIG. 2 is a booleanparameter which indicates whether or not an automobile locator featureis available. The server count Feature 22 indicates how many servers areconfigured. The brand Feature 23 indicates the automotive brand for thesite, and the delivery options Feature 24 indicates which deliveryoptions are supported by this particular website.

The product definitions component models the individual softwareproducts that can be created from the software production line. As shownin FIG. 3, there is an editor 30 from the development environmentshowing a product definition in the infrastructure. Values are selectedfor each feature declaration 21, 22, 23 and 24 shown in FIG. 2,indicating the desired customized feature desired in the end product.The software product in this example will include the auto locator 31,will operate on a 10-server configuration 32, will display the Fordbrand of vehicles 33, and will support factory and dealer deliveryoptions 34.

The automatons component encapsulates software artifact variants thatexist in the software production line and the automaton logic forselecting among the variants. Shown in FIG. 4 is a logic editor 40 fromthe development environment of the disclosed system and method, whichviews the automaton logic and instantiates an individual automaton byactuation with a product definition. In the illustrated example, theautomaton logic selects among two file variants, normal.java 41 andstub.java 42, depending on the value of the boolean feature declarationauto locator.

The partition composition component models the combination of partitioncustomization that can be composed in the software production line.

The automaton actuator portion of the present invention is responsiblefor configuring an individual software product from the source files,declarations, definitions, and automatons in a software production line.Specifically, the automaton actuator configures an individual softwareproduct according to a selected product definition by actuating eachautomaton in the software production line with product definition. Forexample, if the automaton actuator were applied for the Ford productdefinition, as shown in FIG. 3, the automaton logic shown in FIG. 4would be activated to select the normal.java variant since the autolocator value is defined as true. By actuating all of the automatons ina software production line, a complete individualized software productwith all desired custom features can be configured. The disclosed systemand method for creating individual software products in a softwareproduct family can be used according to any one of three individualapproaches described below.

The first approach for using the software mass customization system andmethod of the present invention is the proactive approach shown in FIG.5. In the proactive approach, a software developer analyzes, designs,and implements a complete software mass customization production line10A to support the full scope of individual software products needed inthe foreseeable future. From the domain analysis and design, a completeset of common and varying software artifacts, feature declarations,product definitions, and automatons are implemented by the softwareproduction line 10A to produce individual software products 51, 52 and53.

The second approach 60 for using the software mass customization systemand method of the present invention is called the reactive approach asshown in FIG. 6. In the reactive approach, a software developerincrementally grows its software mass customization production line 10Baccording to the demand for new individual software products 64, 65, 66and 67 and new requirements for existing software products 61, 62 and63. Common and varying software artifacts, along with the featuredeclarations, product definitions, and automatons, are incrementallyextended in reaction to the new software requirements. This incrementalapproach offers a quicker and less expensive path into software masscustomization.

The third approach 70 for using the software mass customization systemand method of the present invention is called the extractive approach.In the extractive approach, the software developer capitalizes onexisting customized software systems 71, 72 and 73 by extracting commonand varying software artifacts into a single software production line10C. In the extractive approach, the feature declarations, softwareproduct definitions, and automatons are created as the variations in thesource code are identified during the extraction. This high level ofsoftware re-use enables a software developer to very quickly adopt asoftware mass customization process to produce individual softwareproducts 74, 75 and 76.

The foregoing three approaches for use of the disclosed system andmethod are not mutually exclusive. For example, another approach is tobootstrap a software mass customization effort using the extractiveapproach followed by use of the reactive approach to incrementallyevolve the software production line over time.

A more detailed explanation of the proactive, reactive and extractiveapproach for using the disclosed invention follows.

The proactive approach 50 to software mass customization shown in FIG. 5is similar to the waterfall approach for the creation of single softwaresystems. The use of the proactive approach 50 is appropriate when therequirements for the set of individual software products needed,extending to the far future, are well defined and stable. The proactiveapproach 50 requires considerable up front effort; however, this upfront effort drops off sharply once the creation of the softwareproduction line has been completed.

The high level tasks for the proactive approach 50 are as illustrated inFIG. 5, specifically:

-   1. Perform a domain analysis and scoping to identify the software    artifact variation to be supported in the software production line.-   2. Model the production line architecture to support all individual    software products in the software production line.-   3. Design the common and variant parts of the individual software    product.-   4. Implement the common and variant parts of each individual    software product using the declarations, definitions, and automatons    of the disclosed system and method.

Once the software production line 10A has been implemented, all thatremains is to create individual software products 51, 52 and 53 asneeded. Using this proactive approach 50, if new software products areneeded, they can be created by simply adding a new software productdefinition into the infrastructure of the software production line 10A.Maintenance and evolution are performed directly on the single softwareproduction line 10A.

The second or reactive approach 60 to software mass customization shownin FIG. 6 is an incremental approach. Use of the reactive approach 60 isappropriate when the requirement for new individual software products64, 65, 66, and 67 in the software product family is somewhatunpredictable. For example, when unexpected software requirements fromnew buyers of software are common, the reactive approach 60 should beused. The reactive approach 60 allows for a rapid adoption of masscustomization since a minimum number of individual software products areincorporated in advance.

The high level tasks for incrementally adding a new product using thereactive approach are:

-   1. Characterize the requirements for the new individual software    products relative to what is currently supported in the software    production line 10B.-   2. Determine if the new individual software products are currently    within the scope of the current software production line 10B. If so,    skip to step 4. If not, proceed to step 3.-   3. If the new individual software products are not within the scope    of the current software production line 10B, then perform the “delta    engineering” to the software production line 10B on any or all of    the declarations, automatons, common software, and definitions to    extend the scope of the current software production line 10B to    include the new individual software product requirements.-   4. Create the software product definition for the new individual    software products by selecting values for each of the feature    declaration parameters.

Use of the third or extractive approach 70 shown in FIG. 7 to thesoftware mass customization is appropriate when there is an existingcollection of customized individual software products 71, 72 and 73 thatneed to be reused for new software products 74, 75 and 76. It is mostappropriate when the collection of individual software products 71, 72and 73 has a significant amount of commonality and the differences amongthem are consistent.

It is not necessary to perform the extractive approach 70 to softwaremass customization for all of the pre-existing individual softwareproducts 71, 72 and 73 at once. For example, a subset of thehigh-payoff, actively used individual software products might beextracted initially, and then the remainder of individual softwareproducts incrementally extracted as needed.

The tasks associated with the extractive approach 70 are as follows:

-   1. Identify commonality and variation in the existing individual    software products 71, 72 and 73.-   2. Factor the commonality and variations into a single software    production line 10C by:    -   a. Creating a single copy of the common software;    -   b. Creating feature declarations that model the scope of        variation among the existing software products;    -   c. Encapsulate variation points into the automatons;    -   d. Program the automaton logic to map declaration parameter        values to variant selections in the automatons;        -   e. Create the software product definitions for the desired            individual software products by selecting values for each of            the individual software product feature definition            parameters.

After the software production line has been populated, individualsoftware products are created as needed using the automaton actuator.Mass customization of individual software products now becomes the modeof operation, as the focus is shifted to maintaining and enhancing thesingle software production line.

One alternate embodiment of the disclosed invention may include two wayautomaton actuation. In two way automaton actuation the real data fileor real data file directory that is presented in the place of thevirtual data file or virtual data file directory during normal actuationcan be subsequently modified by the software developer. The softwaredeveloper can then run the automaton actuation in reverse to push anymodification back into the automaton. The next automaton actuation willnow include the modification.

Another alternative embodiment is based on the fact that the need forparameters used for an automaton in one area of an individual softwareproduct may be different from the parameters needed in another area ofthe software product. To prevent a large number of irrelevant parametersbeing available for all of the automatons, the software product can bepartitioned into scopes such that only a subset of parameters apply tothe automatons in each partition. A description for the assembly ofcustom partitions into a custom product instance is required for thisalternative embodiment.

There are multiple alternative embodiments for automaton containers.Each automaton encapsulates logic and different source code variants foractuating different real files and real data file directories in placeof the virtual data files and virtual data file directories. Anautomaton container can be implemented in a variety of different ways.Examples of implementing an automaton container include the use of aconventional directory, encoding all of the automaton information in asingle file, extending a file system to implement the automaton concept,and extending a configuration management system to implement theautomaton concept.

OPERATIONAL EXAMPLES

For a still better understanding of the system and method of the presentinvention, consider a company which develops e-commerce software forretailers. One of the retailers sells bicycles; a second retailer sellswedding rings; and a third retailer sells pianos. As between the threeretailers, they sell products into Europe, into the United States, andinto Canada. Each of the three retailers wants a website where buyerscan order and pay for the particular product ordered. One of the threeretailers wants a website to offer a “shopping cart” service wherebuyers can temporarily “store” purchases between Internet purchasingsessions. The other retailers do not want this feature on theirwebsites. Some of the three retailers want their products delivered to adealer for pickup; while others desire to offer pickup of the purchasedproduct at the factory.

The first step to producing individualized software products meeting theneeds of the three retailers in the example using the present inventionis to enumerate the individual software products offered to theretailers and the ways that they differ. For example, a softwaredeveloper may have different retailers who want to use differentwebsites. The websites will vary by the merchandise being sold, forexample, bicycles, wedding rings, and pianos; the business location, forexample, Europe, U.S., and Canada; whether the retailers offer ashopping cart service on their website; and the delivery arrangementsfor the retail product sold.

To build each one of these individual software products, the softwaredeveloper uses 20 different software components. Most of the componentsare common across all retail sales applications, such as that componentwhich manages payment using an on-line credit card transaction. However,other components exist in different versions of the retail softwareproduct depending on how it is used. The second thing to be done is tolist all of the common artifacts and all of the versions of the variantartifacts and then define what artifacts are used in each individualretail software product. Shown in FIG. 8 is a screen 80 displaying thesoftware development environment. On the right side of the screen 81 arethe feature declarations for the software production line. Anenumerative variation 82 means that one value must be selected. A setvariation 83 means 0 or more values can be chosen. On the left side ofthe screen 84 is the inventory of the product definitions and thesoftware components that are included. The six products listed underDefinitions begin with Bikes Europe and end with Rings, U.S. The fiveautomatons that have different versions in the different softwareproducts are marked with a gear symbol. Note that automaton formain.java 85 is expanded, showing that it comes in two variants. Thelogic file contains the simple expression that associates each variantof the automaton with the combination of feature declarations that causeit to be selected for an individual software product. The complete listof common files that are included in all software products are in a listat the bottom of the left side of the screen 80.

Note that in FIG. 8, the entry “Bikes, U.S.” is chosen. This means thatthe website that is going to be built is going to be for the retail saleof bicycles in the U.S. from a factory and where the website will offera shopping cart feature.

As shown in FIG. 8, the “button” 86, under the arrow, to actuate thecreation of the customized software product is about to be pressed. Thiscauses the variants of all the automatons appropriate to “Bikes, U.S.”to be made available in a workspace from which the customized individualretail software product can be built.

FIG. 9 shows what happens when the actuation of the creation of thecustomized software product actually occurs. Note that the screen showsus which variants 91, 92, 93, 94 and 95 have been selected. Herein, theversion of delivery file named “factory.java” 91 has been selected, andso forth. The software product associated with “Bikes, U.S.” is nowready to be built.

The disclosed system and method is designed to be independent of thesoftware developer's process for building software. Simply, thedisclosed system and method supplies the correct files to build thecustomized software product, which can now be greatly simplified becauseall concerns about version selection are removed. The disclosed systemand method is also independent of any CM tool because it is irrelevantwhere the data file versions come from. The language is independent; thedisclosed system and method never modifies or even examines the sourcecode. The “artifacts” actually do not have to be software at all. Forexample, the “artifacts” could be chapters in product line requirementspecifications. For example, with almost no change, the foregoingdescription could have related to generating a requirements document forthe “Bikes, U.S.” retail software product.

The end result is that the disclosed system and method producesdifferent individualized custom software products by assemblingdifferent collections of files, according to parameters that expresspossible customizations. As previously indicated, the assembling ofdifferent collections of files is accomplished as follows:

-   1. A software mass customization infrastructure consisting of    special-purpose files and directories that are added to existing    software to create a software mass customization production line.-   2. A software mass customization development environment to browse,    create, organize, and maintain the infrastructure for the software    mass customization production line.-   3. A software mass customization actuator to activate the software    mass customization production line to produce custom individual    software products.

A second example illustrates how the disclosed system and method is usedfor globalization and localization, or internationalization, of aU.S.-Centric software system as shown in FIG. 10.

This example is best understood by understanding that a U.S.-Centricsoftware product line 101 can be viewed as a software production line10D with no variants. That is, the US-Centric software product 101 canserve as the initial basis for the creation of the software productionline 10D. The process is begun by directing the disclosed system andmethod to create a new software production line 10D and thereby point tothe root of the US-Centric software product source tree. The disclosedsystem and method creates the initial infrastructure for the softwareproduction line and creates empty declarations and definitions. TheUS-Centric software product is now a software production line 10Daccording to the disclosed system and method.

Next, the key globalization dimensions of variation for the softwareproduction lines are declared 102. These dimensions may come from acombination of industry standards, company standards, and from ananalysis that is specific to the software product and its targetedcustomer base. Typically, a system architect is responsible for creatingand maintaining the declarations for a software production line.

Globalization values that may be declared include:

-   -   An enumeration of specific countries to include which countries        will be selected for individual software products;    -   A set of religions that potential users may belong to;    -   A boolean variable indicating whether or not to use European        currency or local currency;    -   An integer variable expressing a taxation code;    -   An enumeration or string that models the language of dialect for        textual display;    -   A character to model diplomatic status or possible immunities of        a user group;    -   An enumeration to model the citizenship of the users, such as        U.S. citizens working in a foreign country.

If the initial target collection of localized individual softwareproducts is known initially, these can be defined using the productdefinition editor 103. A named product definition is created for eachindividual software product to be instantiated from the softwareproduction line.

The task of defining a software product simply consists of selecting avalue for each of the feature declarations.

The task of creating a software product definition is typically createdby a system architect.

The next step is to enter the source base of the US-Centric softwareproduct where US specific areas are identified in the source code thatmust be generalized to support other locales.

The files that need to be globalized are converted from common files toautomatons using the disclosed system and method. For example, atimesheet form in a US application may have an overflow area to computeovertime hours worked, where in Germany this same form must provide awarning when the legal maximum number of hours worked during a week isbeing approached rather than flowing into overtime. These two time sheetvariants can be encapsulated into a single timesheet automaton. Thelogic description in this automaton is then programmed to select amongthe US and German file variants using the declaration variable andvalues.

After the declarations, definitions, and automatons have been created toform a complete software mass customization production line, thelocalized software products 105, 106 and 107 for different regions canbe produced. The actuation operation 104 of the disclosed system andmethod takes a software product definition as input and creates acorresponding software product as output.

After the software production line has been established, all maintenanceand evolution of the software production line is performed on the singlesoftware production line rather than on individual software products.For example, a bug fixed once in common software artifact is then fixedfor all individual software products produced by the production line. Asrequirements for new locales are introduced, the declarations,definitions, and automatons are incrementally extended as necessary,thereby the entire software production line evolves as a whole inconfiguration management so that one can always go to the softwareproduction line to reactuate and reproduce any product that waspreviously shipped.

Those of ordinary skill in the art will understand that numerous otherembodiments of the foregoing invention are enabled by this disclosure.Such other embodiments shall fall within the scope and meaning of theappended claims.

1. A method for the mass customization of a software artifact to createone or more software products in a software product family comprising:creating software artifacts with common data files and commondirectories, said software artifacts also having one or more fileautomatons, wherein each of said file automatons serves as a proxy for areal data file that varies between software products within a softwareproduct family, said software artifacts also having one or moredirectory automatons, wherein each of said directory automatons servesas a proxy for a real directory that varies between said softwareproducts within said software product family; defining one or morefeature variations for said software product family, wherein each ofsaid feature variations includes two or more selectable values; creatingone or more feature profiles, each feature profile consisting ofselected values for each feature variation for a desired softwareproduct within said software product family; and using a fully automatedproduct actuator to provide one of said feature profiles to each of saidfile automatons and said directory automatons, thereby automaticallyinstantiating a real data file in place of said file automaton and areal directory in place of said directory automaton to create saiddesired software product.
 2. The method of claim 1, wherein each of saidfile automatons encapsulates the data and logic required to beself-configuring with only said feature profile as input.
 3. The methodof claim 2, wherein said logic and said data reside separately from oneanother.
 4. The method of claim 1, wherein each of said directoryautomatons encapsulates the data and logic required to beself-configuring with only said feature profile as input.
 5. The methodof claim 4, wherein said logic and said data reside separately from oneanother.
 6. A method for the mass customization of a software artifactto create one or more software products in a software product familycomprising: creating software artifacts with common data files andcommon directories, said software artifacts also having one or more fileautomatons, wherein each of said file automatons serves as a proxy for areal data file that varies between software products within a softwareproduct family; defining one or more feature variations for saidsoftware product family, wherein each of said feature variationsincludes two or more selectable values; creating one or more featureprofiles, each feature profile consisting of selected values for eachfeature variation for a desired software product within said softwareproduct family; and using a fully automated product actuator to provideone of said feature profiles to each of said file automatons, therebyautomatically instantiating a real data file in place of said fileautomaton to create said desired software product.
 7. The method ofclaim 6, wherein each of said file automatons encapsulates the data andlogic required to be self-configuring with only said feature profile asinput.
 8. The method of claim 7, wherein said logic and said data resideseparately from one another.
 9. A method for the mass customization of asoftware artifact to create one or more software products in a softwareproduct family comprising: creating software artifacts with common datafiles and common directories, said software artifacts also having one ormore directory automatons, wherein each of said directory automatonsserves as a proxy for a real directory that varies between said softwareproducts within said software product family; defining one or morefeature variations for said software product family, wherein each ofsaid feature variations includes two or more selectable values; creatingone or more feature profiles, each feature profile consisting ofselected values for each feature variation for a desired softwareproduct within said software product family; and using a fully automatedproduct actuator to provide one of said feature profiles to each of saiddirectory automatons, thereby automatically instantiating a realdirectory in place of said directory automaton to create said desiredsoftware product.
 10. The method of claim 9, wherein each of saiddirectory automatons encapsulates the data and logic required to beself-configuring with only said feature profile as input.
 11. The methodof claim 10, wherein said logic and said data reside separately from oneanother.
 12. A method for the mass customization of a software artifactto create one or more software products in a software product familycomprising: identifying one or more feature variations for a softwareproduct family, wherein each of said feature variations includes two ormore selectable values; creating one or more feature profiles, eachfeature profile consisting of selected values for each feature variationfor a desired software product within said software product family; andusing a fully automated product actuator to create said desired softwareproduct by instantiating real data files in place of virtual fileautomatons in a software artifact and by instantiating real directoriesin place of virtual directory automatons in said software artifact,wherein each of said virtual file automatons serves as a proxy for areal data file which corresponds to said values for said feature profileand wherein each of said virtual directory automatons serves as a proxyfor a real directory which corresponds to values for said featureprofile.
 13. The method of claim 12, wherein each of said virtual fileautomatons encapsulates the data and logic required to beself-configuring with only said feature profile as input.
 14. The methodof claim 13, wherein said logic and said data reside separately from oneanother.
 15. The method of claim 12, wherein each of said virtualdirectory automatons encapsulates the data and logic required to beself-configuring with only said feature profile as input.
 16. The methodof claim 15, wherein said logic and said data reside separately from oneanother.
 17. A method for the mass customization of a software artifactto create one or more software products in a software product familycomprising: means for creating software artifacts with common data filesand common directories, said software artifacts also having one or morefile automatons, wherein each of said file automatons serves as a proxyfor a real data file that varies between software products within asoftware product family, said software artifacts also having one or moredirectory automatons, wherein each of said directory automatons servesas a proxy for a real directory that vary between said software productswithin said software product family; means for defining one or morefeature variations for said software product family, wherein each ofsaid feature variations includes two or more selectable values; meansfor creating one or more feature profiles, each feature profileconsisting of selected values for each feature variation for a desiredsoftware product within said software product family; and means forusing a fully automated product actuator to provide said feature profileto said file automatons and said directory automatons, therebyautomatically instantiating a real data file in place of each of saidfile automatons and a real directory in place of each of said directoryautomatons to create said desired software product.